跳到正文
首页
OceanBase
运维避坑
OceanBase运维避坑案例整理
OceanBase运维避坑案例整理
整理自用户提供的《新炬运维避坑指南合集》41
篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 78
个案例 。期数按专辑标题编号；来源链接取自离线文章元数据。
查看或下载 Markdown 原稿
案例目录
第 40
期｜OceanBase 多次出现单台OBserver主机CPU打爆问题分析
专辑文件：02.html，第 1 个案例
查看原文 现象：
某日月结当晚，某OCEANBASE数据库多次出现单台OBserver主机CPU打爆的情况，影响业务资料刷速率。处置过程： 某日月结当晚，某场地接到一套OCEANBASE
v3.2.4.5数据库CPU使用率超限的告警。；经确认为资料刷新P类数据量突增导致，高并发执行sql，瞬时采样高峰在200个并发左右，与出账业务侧人员沟通停止部分刷新进程后，OBSERVER主机CPU逐渐恢复正常。运维建议：
后续在资料刷新业务表上创建最佳联合索引，核查相关sql：substr('S Q L P A R A M ′ , 0, i n s t r (′
第 39 期｜OceanBase
DDL执行失败问题分析
专辑文件：03.html，第 5 个案例
查看原文 现象：
测试集群执行DDL语句，报-4694内部错误，DDL执行失败。处置过程：
查询官网，DDL失败可能原因是集群合并未完成导致；定位合并异常Server；定位到具体合并失败
Zone运维建议：
根据错误编号，可以到官网搜索，确认故障定位方向；主机层面在集成阶段，要确保配置满足OB官方要求(时钟同步/BIOS配置/挂载参数要求等)，可减少后期维护问题
第 39 期｜OceanBase
活跃内存超限问题分析
专辑文件：03.html，第 6 个案例
查看原文 现象： 活跃内存超限导致ddl和insert语句被限流。处置过程：
检查转储状态；oceanbase.__all_virtual_minor_freeze_info；where
svr_ip=运维建议：
长事务会占用锁及内存资源，活跃内存紧张时，转储的表存在长事务未及时提交，会导致转储被卡住；集群存在长事务超1小时，应及时抓取sql，反馈给业务侧整改
第 39 期｜oceanbase
ocp无法正常使用问题分析
专辑文件：03.html，第 10 个案例
查看原文 现象：
测试环境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 个案例
查看原文 现象： 迁移对象在DbCat 响应中不存在。处置过程：
查看oms的dbcat日志，可以定位到内部sql执行报-4258；/home/admin/logs/ghana/Ghana/dbcat.log；在源端业务租户执行日志中的sql同样报-4258运维建议：
迁移前必须做元数据质量检查；字段注释、表注释是 OMS
采集元数据的关键依赖，注释中存在乱码、特殊不可见字符会直接导致元数据查询失败，引发迁移中断
/ 数据丢失。；迁移前必须检查
第 38 期｜OceanBase
clog增长异常问题分析
专辑文件：04.html，第 2 个案例
查看原文 现象： 某套集群近半个月clog增长异常。处置过程：
解析1分钟的clog日志；发现主要的问题表为sp_workf_comm表，1分钟的clog产生量sp_workf_comm大概是270M。；查询ocp视图运维建议： 针对所有核心
SQL，设置执行频次、事务量阈值告警；偏离基线 20%
即触发提醒；；常态化监控核心表的 clog 产生量，建立 clog 增长基线
第 38
期｜OceanBase SYS租户CPU使用率高问题分析
专辑文件：04.html，第 3 个案例
查看原文 现象： 某库SYS租户CPU使用率高。处置过程：
查看ocp的等待队列耗时；可以看到10:34~12:22期间SYS租户的处理性能较低数据库出现队列积压，同时RPC吞吐量入口流量在此期间也出现异常突增的情况，优先排查网络问题；查看sys主节点的网络情况运维建议： 建立 SYS 租户多维度联动监控面板；覆盖
CPU 使用率、RPC 吞吐量、网络丢包 /
延迟、SQL执行（时间、频次），设置基线告警，异常时自动关联相关指标，提升定位效率。；规范监控
SQL 管理
第 38
期｜OceanBase 设置leader命令导致异常问题分析
专辑文件：04.html，第 4 个案例
查看原文 现象：
搭建异地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 个案例
查看原文 现象：
某集团成员批量删除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 个案例
查看原文 现象：
使用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 个案例
查看原文 现象： 使用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 个案例
查看原文 现象：
根据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 个案例
查看原文 现象：
业务反馈前台人员录入生僻字"䶮"，录入之后查询返回乱码。；生僻字在gbk下规避。处置过程：
通过排查发现该生僻字"䶮"，在gbk编码下并不存在。；通过系统函数select
dump(name,16) from
dual，发现对应字段返回的是乱码3F，虽然编码gbk中并不包含该生僻字，但是编码gb18030兼容。gbk编码和gb18030之间字符集不需要转换，直接获取编码。；了解到该特新后，解决办法如下运维建议：
需要手工插入编码到底层数据库；业务需要修改url连接串中的字符集编码，业务全部修改为gb18030；因为该编码和gbk是兼容的，中间不存在字符集转换
第 34 期｜OceanBase
租户CPU抖动问题
专辑文件：08.html，第 2 个案例
查看原文 现象：
在月结场景下，业务数据量翻倍，租户CPU在短时间段被打爆，且影响返回时间较长。；租户CPU抖动：分区扫描。处置过程：
通过问题时间点业务分析；定位到具体的SQL语句，；临时解决办法运维建议：
OceanBase对于多分区场景下，存在较多bug，业务尽量通过分区键限制访问分区，对改表分区进行调整
第 34 期｜OceanBase
程序启动异常
专辑文件：08.html，第 3 个案例
查看原文 现象：
版本后大量程序启动异常，业务测试报错；”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 个案例
查看原文 现象：
集群合并超时（三副本中出现一副本无主且版本未更新）。处置过程：
检查合并版本的情况；data_version,；oceanbase.__all_virtual_partition_table运维建议：
合并超时(-4024)的规避方法（3副本都未更新合并版本）。；查看合并状态；from
__all_zone where name =
第 34
期｜OceanBase 黑屏删除集群导致OCP功能不可用
专辑文件：08.html，第 5 个案例
查看原文 现象：
集群在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 个案例
查看原文 现象： 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 个案例
查看原文 现象： rs异常切主问题分析。排查与原因：
导致RS切主的原因主要有；主机时钟偏移；时钟同步不一致会导致租约过期。处置过程：
判断rs是否发生选举，根据RS启动原理当__all_core_table
1号表无主时，RS就会无主，查询；__all_virtual_election_event_history；表排查RS切主时间。运维建议：
时钟同步优化；使用NTP/Chrony确保时钟同步；；定期检查时钟同步状态。
第 29
期｜OceanBase高并发问题分析
专辑文件：13.html，第 3 个案例
查看原文 现象：
SQL自动限流解决高并发SQL带来的数据库异常。处置过程：
OCP平台检查租户CPU线程使用率，发现故障点的租户线程使用率出现突增且已经打满；；查看dbwait日志，发现故障时间点的XA事务并发累积超过500，因此活跃会话数超过告警阈值；；检查proxy日志发现连接数超限，业务连接数据库有报错。运维建议： 对高并发语句绑定限流 hint
是本次解决问题的关键措施。通过这种方式，能够在短时间内控制 SQL
的并发执行，减轻数据库的压力。；监控与分析
第 29
期｜OceanBasecpu使用率问题分析
专辑文件：13.html，第 4 个案例
查看原文 现象： 接收到营业E库cpu使用率告警。排查与原因： 大事务导致回滚异常超时导致kill
session会话长时间无法完成。属于产品缺陷。处置过程：
登录数据库通过检查；__all_virtual_processlist；查看并发情况，检查发现有大量的kill
sessoin的会话，且session已经进入session_killed状态，但执行很长时间未完成，查看对应的要kill掉的会话是一个insert语句，是一个长事务，检查部署的杀长事务脚本，发现主机后台进程的确起着多个杀长事务脚本，都在杀同一个会话。
第 29
期｜OceanBaseSQL查询超时问题分析
专辑文件：13.html，第 5 个案例
查看原文 现象：
业务侧反馈某SQL查询超时，对应集群cpu有明显升高趋势，表访问报错4038。排查与原因：
enable_rebalance打开之后白天有时会进行副本迁移的操作，迁移数据完成后local_cache信息未正常刷新导致无法正常访问leader分区数据导致报错分区无主。处置过程：
登录数据库检查；__all_virtual_processlist；检查并发情况，发现有异常sql执行并发较高，且执行时间过长，且与业务提供SQL相匹配。
第 29
期｜OceanBase存过执行超时问题分析
专辑文件：13.html，第 6 个案例
查看原文 现象： 存过执行超时判断和解决。处置过程：
业务反馈一个存过执行1h多后超时了。；配合进行问题复现，通过；__all_virtual_processlist运维建议： 避免存过书写过长，同时减少使用insert
into select语句插入过多的数据。
第 29
期｜OceanBasecpu使用率高问题分析
专辑文件：13.html，第 7 个案例
查看原文 现象：
由于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 个案例
查看原文 现象： 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 个案例
查看原文 现象：
运维批量更新100张表，每张表64个分区，造成租户线程使用率100%，队列积压，导致数据库出现大量慢SQL。处置过程：
通过分析故障时段observer日志，发现有日志同步慢；（errcode=-4389）；的情况出现，同时有出现req_queue队列积压的情况；运维建议：
在生产环境，对执行的SQL要预先了解排查表结构和表数据量，不盲目执行；不大批量的执行DML语句，可能存在性能风险；对长时间执行中的SQL要及时终止，避免影响整个数据库
第 29
期｜OceanBasenvl函数无返回问题分析
专辑文件：13.html，第 10 个案例
查看原文 现象： OB数据库中sql
where条件中使用nvl函数，在oracle数据库中可以返回结果，而在OB数据库中总是返回空行。处置过程： 应用侧反馈有一条SQL
where条件中使用了；where rownum<nvl((select count(1) from
XXX),5)；,该SQL在Oracle数据库有返回结果，在OB数据库中一直返回空行运维建议：
ORACLE数据库与OB数据库存在一些相同功能但是底层处理机制不同的情况，提前与原厂沟通确认还有哪些原厂已知的oracle与OB存在差异的地方，提前进行规避。
第 25
期｜OceanBase数据库迁移后高耗SQL
专辑文件：17.html，第 1 个案例
查看原文 现象：
某客户反馈有广播一直处理中，重发后处理成功，但第二次重发失败，导致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 个案例
查看原文 现象：
某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 个案例
查看原文 现象：
从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 个案例
查看原文 现象： 业务侧反馈程序中执行；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 个案例
查看原文 现象： 收到一线人员前台界面提示程序报错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 个案例
查看原文 现象：
生产环境单点登录的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 个案例
查看原文 现象：
oms迁移过程中，发现反向增量延迟2小时以上，查看日志发现有deadlock日志输出，导致链路延迟。处置过程：
在plsql通过语句查询，确认是否存在死锁，查询出具体的信息，确认存在死锁。；通过修改
Incr-Sync 增量同步组件中的并发参数workerNum":int 1
修改成1，使之串行化运行。；等待当前事务提交后，将并发参数workerNum":int
64 修改成原先值。运维建议：
加强链路监控完善预警机制；本次故障暴露了我们在链路监控和预警机制方面的不足。未来，我们需要将加强对链路的监控关注，建立更为完善的预警机制。通过实时监控系统的运行状态、日志输出和性能指标，我们能够及时发现潜在的问题并采取有效的应对措施，从而最大限度地减少故障对业务的影响。；优化并发处理
第 25
期｜OceanBase数据库提前转储
专辑文件：17.html，第 8 个案例
查看原文 现象： 慢SQL导致节点提前转储问题。处置过程：
OCP分析故障时间段memstore使用情况；发现memstore可用内存被挤占，导致计算出来的阈值下降，触发了节点提前转储。；从sqlaudit中捞取的可疑SQL运维建议：
禁止未经测试的大结果集SQL生产上线；本次故障的发生，直接原因是某条SQL语句缺少筛选条件，导致生成了庞大的中间结果集。这提醒我们，在SQL语句上线之前，必须进行充分的测试，确保其执行计划合理、内存占用可控。对于可能产生大结果集的SQL语句，更要进行严格的审查和测试，避免其未经测试就直接在生产环境中使用。；业务侧严格遵守上线评审流程，未经评审通过的SQL不允许直接上线
第 25
期｜OceanBase数据库登录慢
专辑文件：17.html，第 9 个案例
查看原文 现象： 用户反应登录很慢。排查与原因：
在中，可首先检查obproxy机器是否hang住或性能异常。obproxy作为请求转发的关键组件，其性能状态直接影响用户登录速度。；部分会话登录很快而部分卡住的情况，可考虑是否与会话管理或临时表使用有关；在OceanBase的某些版本中，会话ID复用机制可能导致临时表删除开销过大，进而影响登录速度。因此，在中应关注临时表的使用情况和会话管理策略。处置过程：
黑屏尝试重复登录；发现有一部分会话连接很快，一部分会话连接会卡住很久。初步分析可能是用户使用F5转发时，对应obproxy宕机，ocp查看obproxy正常。；查看登录时间段的observer.log运维建议：
登录均失败的排查方向一般与observer实例本身无关；为避免临时表过多导致的性能问题，用户在使用临时表时注意控制数量。不要在同一会话中创建过多的临时表，以免增加删除开销和影响登录速度。
第 25
期｜OceanBase数据库至灾备集群后部分应用验证失败
专辑文件：17.html，第 10 个案例
查看原文 现象：
OB灾备切换演练，灾备集群切换为主集群后，部分应用功能验证失败。处置过程：
分别进入主备集群查看主备角色已经切换成功。排查应用的数据库连接配置，数据库连接配置均为域名，域名解析也已切换至灾备机房IP。；ssh连接应用主机，netstat查看正在连接的会话，发现有很多会话还是访问的原主机房IP。ssh原主集群OB主机查看日志，发现仍有sql请求持续过来，但因为已切换为备集群只读模式，这些sql都执行失败了。；通知行方应用发现连接池存在长链接未关闭，持续提供数据库访问导致。咨询其他分行切换情况，也存在访问IP为原主机房，但应用任然可以正常入库至灾备集群。查看发现OBproxy的启动方式为RSlist，其他分行是configurl。运维建议： 接池配置和状态引以重视
第 24
期｜OceanBase数据库全备失败问题分析
专辑文件：18.html，第 8 个案例
查看原文 现象：
某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 个案例
查看原文 现象：
网络瞬断导致两套集群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 个案例
查看原文 现象： 执行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 个案例
查看原文 现象： （OceanBase）业务误操作删除表。处置过程： 检查集群回收站是否设置运维建议：
确认备份和归档是否正常；依赖备份和归档进行单表恢复到一个新的临时租户（3.x）；通过obdump/datax/oms/outfile的方式把数据导回原库
第 19
期｜OceanBase集群执行脚本效率下降
专辑文件：23.html，第 2 个案例
查看原文 现象：
业务反馈其他数据量类似的集群一个脚本大概执行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 个案例
查看原文 现象：
资源新增弱读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 个案例
查看原文 现象： oceanbase数据库磁盘使用率忽然升高。处置过程：
查看磁盘空间使用情况；__all_virtual_disk_stat；查看临时空间的使用情况运维建议：
深入理解系统内部机制；掌握系统表与视图
第 19 期｜OceanBase某租户CPU
100%问题
专辑文件：23.html，第 5 个案例
查看原文 现象： 某现场某租户出现CPU 100%问题。处置过程：
通过processlist抓取当时；sqlid（EE7641A6834AF923F447DF03A78C2B44）；发现当时时间点存在sql并发很高，而且执行时间长，影响了当时cpu使用率异常增长。运维建议：
1）SQL优化；避免全表扫描；全模糊匹配（如LIKE
'%keyword%'）和函数转换（如UPPER）经常导致数据库无法利用索引，从而引发全表扫描。这极大地增加了数据库的负载，特别是在大数据集上。理解这一点并尽可能避免这些操作，或者通过其他方式（如文本搜索引擎）来实现类似的功能，是提升查询性能的关键。
第 19 期｜OceanBase
oms全量迁移卡住
专辑文件：23.html，第 6 个案例
查看原文 现象：
oms迁移过程中，全量迁移卡住，链路没有报错但是实时流量为0KB/s。处置过程：
查看全量导入组件中的日志，显示查询sql超时；将执行超时的SQL语句拿到源端执行，显示超时；查看了这条语句的执行计划explain
sql 中显示耗时运维建议：
1）深入理解SQL执行计划与优化器行为；执行计划的重要性；在处理数据库迁移或优化性能时，了解SQL的执行计划是至关重要的。执行计划展示了数据库如何执行查询，包括使用的索引、连接方法、排序操作等。通过EXPLAIN命令查看执行计划，可以清晰地看到哪些步骤可能成为性能瓶颈。
第 19
期｜OceanBase oms迁移数据中全量组件异常中断
专辑文件：23.html，第 7 个案例
查看原文 现象： oms迁移数据中全量组件异常中断。排查与原因：
过滤日志中相关报错的涉及的用户及表信息，定位报错表；；在源端侧锁定迁移割接范围中包含的rowid字段的全部表，未发现；；确认是否oms版本bug,链路重新复制，在预检查阶段未发现rowid
的排除提示，说明割接对象中未包含rowid字段的表；处置过程：
oms迁移全量业务表，单条链路表数量40张；；操作oms版本4.1.0；；涉及链路结构迁移+全量迁移+增量迁移+反向增量。运维建议：
）OMS版本与目标数据库结构的兼容性检查至关重要；在数据迁移前，应详细检查OMS工具与目标数据库中的特殊表结构是否兼容，尤其是针对OMS版本不支持的表类型；（如索引组织表IOT）
第 19 期｜OceanBase
数据库主机宕机
专辑文件：23.html，第 8 个案例
查看原文 现象：
主机的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 个案例
查看原文 现象： Oceanbase 备份恢复失败。处置过程：
通过命令查看恢复历史记录，恢复状态为失败。；发现备份环境与恢复环境的OB版本信息不一致，将恢复环境的版本升级后，再次执行恢复成功。运维建议：
在执行备份和恢复之前，确保所有环境中的软件版本完全一致。如果必须进行版本升级，同时更新备份环境和恢复环境，以避免兼容性问题。；自动化版本检查；在备份和恢复的流程中加入自动版本检查步骤，如果发现版本不一致，自动提示或阻止操作，减少人为错误。
第 16
期｜租户的占用内存大小超限分析
专辑文件：26.html，第 1 个案例
查看原文 现象： OB500租户的占用内存大小超限，占用内存 100.08
GB。处置过程：
前期观察，后期进行重启observer进程，释放内存。；Ocean Base
3.2.3集群长时间不重启；（超过200天）运维建议： 重启集群或者升级3.2.3
bp9以后版本，目前为3.2.3
bp5版本。；计划定期重启；定期重启可以作为临时措施，以防止系统长时间运行后出现性能降低或资源泄漏。
第 16 期｜迁移速度变慢分析
专辑文件：26.html，第 5 个案例
查看原文 现象：
OMS配置了反向增量的用户后，迁移速度变慢，由几百MB每秒降至几十KB每秒。处置过程：
版本4.1.0的OMS，配置了oms_drc用户后，迁移链路会自动设置；sink.enablePartitionBucket；参数为true。对于分区数特别多的表，就会迁移特别慢。运维建议：
参数文档化和理解；确保团队成员对OMS及其相关配置参数有充分的理解。这包括了解每个参数的作用、适用场景和潜在的副作用。；制定配置变更策略
第 16
期｜OB集群从OCP中无法迁出
专辑文件：26.html，第 7 个案例
查看原文 现象：
一备集群被其他OCP接管并解耦为主集群，原OCP无法管控进行迁出失败。处置过程： 通过连接ocp
meta元数据库，删除集群信息；delete from ob_server where cluster
id；delete from ob_zone where cluster_id运维建议：
增强集群监控；确保所有集群的状态和归属都被实时监控并记录，这有助于在类似情况下快速了解集群的当前管理状态。；集群管理策略
第 16
期｜OMS迁移ROWID类型数据
专辑文件：26.html，第 8 个案例
查看原文 现象： OMS标准情况无法迁移ROWID类型数据。处置过程： precheck.skippable_flags =
{"DB_DATA_TYPE":true}；忽略类型检测。；通过dbcat导出表元数据，替换rowid类型为varchar2(18)，将DDL语句在目标租户执行创建表结构。运维建议：
数据类型映射验证；在迁移前彻底测试和验证数据类型映射的准确性，确保 ROWID
转换为 VARCHAR2(18)
后，所有数据都能正确表示且不会引起数据丢失或错误。；数据验证和审计
第 15
期｜OCP主机与OB主机检验时钟差过大问题分析
专辑文件：27.html，第 2 个案例
查看原文 现象： 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 个案例
查看原文 现象： OMS正向链路仅同步表结构，反向回流报错。处置过程：
修改增量同步组件参数；coordinator.allowRecordTypes = "；source.ignoreDdl
= false运维建议：
允许所有记录类型；确保配置文件或同步参数中允许同步所有类型的数据库操作，包括DELETE、INSERT、UPDATE以及DDL。这有助于保证数据和结构的完整性都得到同步。；启用DDL同步
第 15
期｜回流导致OB节点CPU使用率超高
专辑文件：27.html，第 7 个案例
查看原文 现象：
OMS回流导致OB节点CPU使用率超高或创建ob-oracle全量、增量迁移链路。处置过程：
参数，减少数据字典访问；slik.isPreLoadAllTableSchema =运维建议：
调整批处理大小；减小每次同步的批处理大小，可以降低单次操作对CPU的压力，但可能会增加总体同步时间。需要根据具体情况调整以找到最佳平衡点。；如果可能，考虑采用异步处理数据的方法，这样可以平滑CPU使用率，避免高峰时段CPU使用率过高。
第 15 期｜回流链路报错处理
专辑文件：27.html，第 8 个案例
查看原文 现象： 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 个案例
查看原文 现象：
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 个案例
查看原文 现象：
因生产环境OCP密码不符合客户安全管理规范，在更新密码后,部署新机器时OAT
报密码验证失败，无法通过OAT进行主机初始化推送。处置过程： 登录OAT 容器；docker exec；it oms
bash运维建议： 配置管理工具；使用如 Ansible、Chef 或
Puppet
等配置管理工具，可以帮助自动化配置文件的更新和部署，确保所有相关的组件都使用最新的配置。；密钥和密码管理
第 14 期｜Oceanbase
oms增量迁移延迟处理
专辑文件：28.html，第 10 个案例
查看原文 现象：
生产环境割接时，通过oms数据迁移mysql到obmysql,业务停止服务后，增量延迟一直增长无法正常进行正向切换，按照
Oracle 割接经验切换日志无效果。处置过程：
检查数据库是否还有连接在；information_scheam.processlsit;；SHOW MASTER
STATUS运维建议：
限制大量的写入操作；在割接过程中，尽量避免执行大批量的写入操作，如
create table as select
可能会产生大量日志，增加迁移过程的复杂度和延迟。；逐步迁移数据
第 13
期｜oceanbase sql执行计划变更，导致cpu使用率打满
专辑文件：29.html，第 2 个案例
查看原文 现象：
业务侧使用mybatis框架生成的SQL在每次有ddl操作后，sql的别名会改变，导致执行计划走选择性较差的索引，导致主机cpu打满。处置过程：
登录数据库后，通过__all_virtual_processlist来确认哪些sql占用的cpu线程较多；对问题SQL进行限流
，并发设置为10；绑定执行计划，并指定正确的索引运维建议：
定期评估数据库索引的有效性和性能影响；确保索引设计与业务查询需求相匹配。避免过多无用索引或缺失必要索引，这两者都可能影响查询性能。；针对那些性能差的
SQL，尝试重写或优化这些查询，
第 13 期｜oceanbase主备延迟
专辑文件：29.html，第 3 个案例
查看原文 现象：
主备集群延迟大，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 个案例
查看原文 现象：
业务侧反馈业务中有慢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 个案例
查看原文 现象： OB
oat中添加主机，precheck环境校验步骤报错openfiles配置值太小。处置过程：
oat上添加服务器主机，服务器用途配置为OBServer；；凭证使用root用户；；操作系统为统信OS
V20；运维建议：
OB数据库对资源限制相关配置要求比较严格，PAM参数会影响OpenSSH会话的资源限制。针对远程检测ulimit资源限制，注意Openssh的UsePAM配置。
第 9
期｜OceanBase迁移过程中影响源生产库性能
专辑文件：33.html，第 1 个案例
查看原文 现象：
某国产化项目数据迁移阶段，在OMS配置数据源，其中Oracle侧数据库属性设置为主库+备库的模式；数据迁移过程中，抽数均从主库抽取，影响Oracle主库性能，影响生产业务。处置过程：
抽数过程中，实时监控主库.ADG库主机网络流量波动情况，发现ADG库主机网卡流量无变化，主库主机网卡流量增涨明显；；检查Oracle库连接会话及执行SQL，发现大量oms服务器主机的进程在连接oracle主库；；经ob研发分析，OMS主备模式下，从4.0.1版本引入的主优先的模式，全量是会自动去连主库导致。后来4.1修复了，优先选择备模式。运维建议：
迁移过程中要多角度全方位对Oracle数据库及主机进行监控，避免产生影响。
第 9 期｜OceanBase备份失败
专辑文件：33.html，第 2 个案例
查看原文 现象：
某国产化项目功能验证阶段，ob数据库备份失败。；2.2
处置方案；检查日志里有current index file is
empty的报错，这个报错一般都是nfs导致的；运维建议：
目前OceanBase数据库国产化项目很多都部署在集团一级云资源池环境中，一级云资源配置复杂，使用时需要进行完整的验证测试。
第 9
期｜OceanBase表存在clob字段，导致查询效率极低
专辑文件：33.html，第 3 个案例
查看原文 现象： 表存在clob字段，导致查询效率极低。；3.2
处置方案；执行select操作，在clob字段加了to_char，效率变快，不加to_char从业务侧看延迟在1.6秒
，加了to_char延迟在100ms以内。运维建议：
提前对陌生字段的表做相应测试。；对查询时间差别大的sql要引起重视。
第 7
期｜OceanBase误删除核心表处置
专辑文件：35.html，第 1 个案例
查看原文 现象：
业务人员误清除CRM核心字典表，导致大量业务异常。处置过程：
业务反馈该表被清除后，尝试基于时间点没有历史数据，检查该表的DDL时间发现做过DDL；；通过flashback进行闪回，发现该数据库未开启truncate闪回，无法恢复删除时间点的数据；；业务反馈可以从其它地市库取数，通过OMS抽数过来进行恢复，2w行数据迁移10分钟未结束，检查表上存在trigger，与业务沟通停掉相关业务，关闭触发器后完成恢复。运维建议：
做好数据库备份很重要；；推动OB改进版本，开启回收站，提高误操作恢复效率。
第 7
期｜OceanBase服务器资源紧张处置
专辑文件：35.html，第 2 个案例
查看原文 现象：
核心库CPU打满，连接数暴增，导致大量业务异常。；2.2
处置方案；可视化运维平台监控到某核心系统数据库CPU异常增高，紧急介入处理抓取异常SQL，此时数据库连接数已满，抓取的SQL都比较慢，很难定位到具体SQL，与客户沟通后重启，重启proxy未能正常恢复，申请切主后仍然未能恢复；运维建议：
做好SQL性能突变监控，及时介入处理；；对OB统计信息优先级进行深入理解；；核心表尽量避免手工收集统计信息。
第 7 期｜OceanBase
SQL远程计划SPF变慢
专辑文件：35.html，第 3 个案例
查看原文 现象： OceanBase
SQL远程计划SPF变慢被放大，效率低下。处置过程：
业务上线之后遇到一条sql超时，执行效率很低，反馈过来要求优化排查。对比其他库查询该sql的执行历史，发现并不慢，对比执行计划也一样，只是远程算子位置不一样，手工将该sql涉及的表副本leader切到同一台server上；；后续在测试环境复现分析，limit截断算子正常是流式执行，外层传参进入内层，匹配到一条数据后就会停止，继续下面的执行，但是慢的执行计划有个exchange的远程查询推入，会进行查询重写，相当于外层传参一次，b表会全表数据拿出来进行一次比对，这个过程进行160次，导致变慢被放大。运维建议：
如果有可能，对可能出现这类问题的业务整理，以使用table_group固定；；关闭rebalance参数，对表副本进行固定，但是时间长了会造成节点负载不均衡；；加强SQL性能监控，对少量这类执行计划进行转换优化。
第 6 期｜OBserver主机CPU 100%
专辑文件：36.html，第 10 个案例
查看原文 现象：
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 个案例
查看原文 现象： 集群合并超时。处置过程：
先临时调大转储内存参数，保证业务不受影响。；检查原因，显示zone3合并未完成，observer日志显示有表转储有问题，修改该表primary_zone,对表级切主后合并正常。；检查observer/rs日志尝试分析是否为表卡住导致合并延迟，尝试表级切主，应急可以尝试重启问题的zone，甚至集群（该类操作谨慎），mem'store使用低的情况下可以暂时先调大转储阈值，提工单帮助分析。运维建议：
目前该问题暂时无法规避，进行数据库升级或者协调OB原厂开发对应的补丁。
第 4
期｜OCEANBASE数据库批量入库报4002处置
专辑文件：38.html，第 5 个案例
查看原文 现象： 生产批量入库SQL报错-4002。处置过程：
代码未经适配直接使用，ob确认为bug，代码中insert
all使用受限，写入数据行数过多时报错。；应用侧更改程序为for循环insert。运维建议：
数据库国产化过程中，务必加强场景测试，严禁代码未经适配直接上线生产。；由OB原厂开发对应的补丁。
第 4
期｜OCEANBASE归档日志延迟处置
专辑文件：38.html，第 6 个案例
查看原文 现象：
oceanbase数据库归档日志存在延迟。；检查归档状态是中断状态，保存下日志，先恢复下，关闭归档重新开启，检查rs日志归档状态变更时间点，去库里查询rs_event历史视图有分区切主操作，该操作为正常rebalance操作，检查该时间点observer日志有找不到clog的报错，检查该日志存在，工单协助分析为日志断流导致，与backup_log_archive_option参数设置有关系，属于正常的偶发。；该参数设置备份优先，不会丢失日志，但是可能会影响集群性能，处置过程：
设置集群可用优先可能会存在日志；关闭归档重新开启。运维建议：
与备份机制有关系，保证集群的高可用的情况下可能会做出备份断流的牺牲，是一种极少遇到的情况。；alter
system noarchivelog；alter system archivelog
第 2
期｜Oceanbase数据库突然hang死
专辑文件：40.html，第 1 个案例
查看原文 现象： 某核心业务系统数据库突然无法登陆，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 个案例
查看原文 现象：
业务数据查询，更新突然缓慢，导致业务大量积压。；经分析该表上存在频繁的DML操作时，可能会遇到一种：虽然表中的数据行数并不大，但是查询和更新的性能出现明显下降。；这种在
OceanBase 中称为Queuing 表(业务上有时又称 buffer 表)效应。运维建议：
为避免此类情况再次发生，将DML操作频繁的表设置为buffer表，这样表的转储与系统的大版本转储时间就不再保持一致，而是根据自身的变化，自行判断转储的时间点。
第 1
期｜ORACLE-OceanBase二阶段事务锁处理
专辑文件：41.html，第 2 个案例
查看原文 现象：
国产化数据库有悬挂事务，期间通过杀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 个案例
查看原文 现象：
某场地Oceanbase数据库主副本节点cpu飙高导致业务连接失败以及大量悬挂事务，其他库CPU和内存无异常，有悬挂事务。处置过程：
检查告警主机CPU使用情况，发现主节点飙高，有超过80%的情况；；利用obstack对cpu飙高的主机抓取堆栈信息，以便根因分析；；杀悬挂事务；运维建议：
加强各类包括OB在内的国产数据库应急方案制定，完善各类国产数据库监控体系，当出现问题后及时根据应急方案进行处置。；根据抓取的堆栈信息，后续定位为数据库BUG，Oceanbase的plan_Cache泄露导致paln_cache打满，