obdiag
obdiag copied to clipboard
obdiag (OceanBase Diagnostic Tool) is designed to help OceanBase users quickly gather necessary information and analyze the root cause of the problem.
### Describe your use case 不同的OBSERVER允许设置不同的参数,对于分布式数据库而言,检查参数设置是否合理十分关键。检查某个租户涉及的OBSERVER上面参数配置存在差异的地方 ### Describe the solution you'd like 功能1-参数全面扫描 1、列出非默认参数列表 2、标识该参数是否在所有OBSERVER上配置都相同,如果存在不同,列出SERVER的,及参数配置 3、分析是否在某个OBSERVER上的参数设置不合理 功能2-某个参数的分析(功能类似功能1) 功能3-关键参数检查(类似功能1,不过需要有内置的关键参数清单) ### Describe alternatives you've considered _No response_ ### Additional context _No response_
silent print
给 rca 的 ddl_disk_full 场景添加 env 参数 ## Summary 修改后效果:  ## Solution Description
### Describe your use case case1: 用户修改 obproxy 参数 request_buffer_length = 16MB,导致obproxy 经常重启,改成 request_buffer_length = 8k就好了,所以希望 obdiag check支持obproxy参数巡检 ### Describe the solution you'd like obdiag check支持obproxy参数巡检 ### Describe alternatives you've...
### Description 现象:一张表在information_schema.tables 中查到的有两条记录,两条记录的原因是__all_table_stat 中同时存在两条object_type=1的记录。 原因分析: 非分区表转分区表 ddl,导致一些视图(如 information_schema.tables/all_tables)会多显示一条记录 observer修复版本: 421bp5/423/431 应急方法:手动删除 __all_table_stat/__all_column_stat 中不符合预期的行(分区表不应该存在 table_id=partition_id=该表id 的记录) 1. 登录到 sys 租户上 2. 切到用户租户:alter system change tenant 租户名 3. 删内部统计信息的行 delete from...
### Describe your use case 创建索引的时候会有一定的空间放大,针对一些大表,非常有必要在创建前评估一下待创建索引的空间。 ### Describe the solution you'd like 创建索引的时候会有一定的空间放大,针对一些大表,非常有必要在创建前评估一下待创建索引的空间。 ### Describe alternatives you've considered _No response_ ### Additional context _No response_
### Describe the bug  同一张表,数据有很多条 ### Environment obdiag 2.x ob 4.x ### Fast reproduce steps select /*+read_consistency(weak) QUERY_TIMEOUT(60000000) */ t1.svr_ip, t1.role, t1.tenant_id,t1.database_name,t1.table_name, ifnull(t2.data_size,0) / 1073741824 as total_data_size_gb from (select...
### Describe your use case 对某个指定时间段内的OBSERVER日志进行深度分析 ### Describe the solution you'd like 1)某个时间区间内日志报错总体分析 1、根据错误和INFO的种类进行归并,给出各类INFO\WARN\ERROR的汇总分析(某类告警信息的数量) 2、对每个ERROR进行深度分析:问题的可能原因,问题集中的时间段(可以按照10分钟划分时段,统计数量),可能的建议(如果有) 3、给出这个时间段内系统风险等级评价,并对发现进行总结 2)某个错误条目的详细解释 输入某个错误文本,自动解析错误信息,并给出分析诊断结果 1、错误汇总的每个关键内容的解析 2、错误可能发生的原因 3、风险评价 4、建议 ### Describe alternatives you've considered _No response_ ###...
### Describe your use case 在4.2.1.3版本及以下,用户租户中如果有多个root用户,即使host不同的情况下,也会出现统计信息任务调度异常,收集失败的情况,例如下面这种  导致用户的统计信息收集任务失败  ### Describe the solution you'd like 目前只能有一个root用户,才能保证收集正常 ### Describe alternatives you've considered _No response_ ### Additional context _No response_
### Description 最近处理的问题,卡合并,最终定位是操作系统磁盘异常,替换节点后恢复正常,希望 obdiag major_hold 卡合并的根因分析可以同时收集或者分析一下操作系统日志是否有异常。 /var/log/messages dmesg -T