本文来自OceanBase 用户的实践分享
随着OceanBase数据库应用的日益深入，数据量不断攀升，单个表中存储数百万乃至数千万条数据的情况变得愈发普遍。因此，部署专门的运维工具、实施针对性的表性能优化策略，以及加强指标监测工作，都变得更为重要。以下为基于我们的使用场景，所采取的一些部署和优化措施分享。
一、OCP部署升级
1．OCP升级
（1）4.2.1BP1升级到4.2.2，本来以为毫无波澜但是下载完毕一键包并完成前期准备工作启动后发现无法登录OCP的服务器了，后台查看日志发现提示需要更新一下admin用户的权限，有小伙伴后续如果遇到密码正确就是无法通过监测的时候需要注意查看一下是不是提示admin账户权限不足使用echo "admin ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers更新一下权限设置应该就好了。
（2）OCP升级进入系统以后系统自动更新ocpAgent代理工具但是，这个版本跟4.2.1一样存在ocpAgent安装异常（OCP升级服务于本服务在一个设备情况下ocpAgent会报stat /home/admin/ocp_agent/pkg_store/ocp-agent-ce-4.2.1-20231208144448.el7.x86_64.rpm: no such file or directory解决方案也比较简单直接复制这个文件到这个位置即可重试）
（3）随后是升级OBProxy集群节点到最新版本，一切都顺利完成后开始测试相关告警功能和测试新增的监控大盘功能和之前提交的（UI错位等问题的解决情况），测试后发现UI问题已经基本解决完毕，发现了一处新的UI问题已经提交。
2．ES部署及OCP接入
为了让日志能进行链路查询记录，需要部署ES和OpenSearch，使用docker按照官网教程部署了OpenSearch和ES并配置相关信息后重启OCP即可接入，接口查看ES的记录情况发现均无异.（配置地址：https://www.oceanbase.com/docs/common-ocp-1000000000584788）
二、警告配置和一些异常处置/性能优化
（1）部署完毕后第一个告警就是时间不同步，但是我通过chrony测试发现一切正常，ocpAgent查看监控数据NTP时钟便宜数据也是正常范围。
（2）将该问题以及相关日志提交到问答论坛后很快就有相关专业工程师解答并提出测试说明，通过测试发现Debian系列系统存在clockdiff在sudo下权限不足的问题，回复为已知问题，正在修复。于是听取建议我将这个告警进行了屏蔽。
（3）性能异常警告：当天晚上发现一个"SQL 巡检，SQL 性能下降"的问题，一早通过OCP查看后发现是一个SQL存在超过平均查询时间较多的情况的一个告警。但是点击SQLID无法跳转到SQL详细信息页面，查看F12发现不存在该资源。
（4）黑屏问题定位：通过黑屏模式查询[select svr_ip, plan_type, elapsed_time, AFFECTED_ROWS, RETURN_ROWS, tx_id, usec_to_time(REQUEST_TIME), substr(query_sql, 1, 10000) from gv$ob_sql_audit where sql_id='B7A34188E00F96CA660B2D39A3968328' order by elapsed_time desc limit 10;]找到了对应ID的SQL情况，使用该SQL到OCP对应租户的SQL诊断工具中搜索该SQL前部分关键词就获得了对应SQL请求信息。
（5）性能优化：通过查看索引情况以及字形情况以及针对SQLID进行链路查询发现了部分字段没有命中索引以及根据优化建议发现索引建立不足以及表设计不合理的三个问题。针对索引问题重新建立了索引。针对表设计不合理主要体现在当前表单为超大型表，数据量过千万，但是没有进行分区设计，也没有进行分段设计导致数据检索存在扫表情况，于是针对当前表进行了功能拆分划分了历时数据和热数据，历时数据清理到历史表并做分区处理，热数据存留当前表保障当前业务。
（6）SQLID无法连接异常提交：通过本次性能优化发现告警部分的SQLID无法被定位到SQL详情，通过后续查询后发现URL的[/diagnosis/1/realtime/2]这个部分应该为对应的集群和租户在当前环境下位[/cluster/1/tenant/2]修改后即可定位到SQL详情，发现该问题后就将相关问题通报到官方相关人员进行记录。
三、基于obdiag的一些集成化开发和畅想
1．obdiag是一个敏捷测试工具是ob官方的一个有效的集群日志收集和巡检的工具，在工作中可以提供异常建议以及指定脚本巡检等功能，在我的日常工作中也充当着重要的伙伴角色。
2．但是obdiag只有本地黑屏执行，配置文件也比较麻烦且报告也是用符号构成的，针对核心运维还好但是不可以进行任务分发到不同员工进行巡检基于该需求，我们计划开发一套带权限管理支持多人巡检，支持报告转换为Json并可视化的一套工具用于辅助多人运维的场景。
3．目前实现：
（1）已经完成报告的Json序列化实现，通过Go语言已经完成了报告的解析工作
（2）数据结构：
type Table struct {
TableName string
ColRows []TaskReport
}
type TaskReport struct {
Task string
TaskReport string
}（3）报告解析：
func parseTable(input string) ([]Table, error) {
lines := strings.Split(input, "\n")
var table []Table
for _, line := range lines {
// 检查是否是表头行或分隔行
if strings.HasPrefix(line, "+") {
continue
}
// 按分隔符 "|" 分割
cols := strings.Split(line, "|")
if len(cols) < 3 {
continue // 如果不是数据行，跳过
}
taskName := strings.TrimSpace(cols[1])
taskReport := strings.TrimSpace(cols[2])
// 如果是表名行，创建一个新的表
if taskReport == "" {
table = append(table, Table{
TableName: taskName,
})
continue
}
// 如果是表头行，跳过
if taskName == "task" && taskReport == "task_report" {
continue
}
// 将提取的数据添加到切片中
table[len(table)-1].ColRows = append(table[len(table)-1].ColRows, TaskReport{
Task: taskName,
TaskReport: taskReport,
})
}
return table, nil
}（4）通过上述方法我们成功实现了数据解析工作，后续将结合gin框架等一些框架实现数据入库和可视化操作并实现可视化脚本以及可视化巡检执行和可视化报告解析。
（5）秉承着OB社区氛围建立本项目在完成基本功能后将全面开源到Github并在社区进行发布。
四、一些OceanBase的使用感想和未来期待
1．OB是国产开源分布式数据库性能和部署以及开源社区氛围最好的选择，这也是我们正式项目的选择，在我们公司的CRM项目中已经稳定运行并使用了一年时间，其中版本从3.xx升级到现在的4.2.1BP4每一次升级都能感受到团队的努力付出以及听取社区的各种建议意见。
2．有浓厚的社区氛围才能使得一个开源产品能够有生命力，才能催生企业产品有更多的价值，相信OB在未来的道路上能越走越远。我们也愿意陪着OB一起成长，为社区添砖加瓦贡献自己的力量和智慧。
3．未来我们将引入更多系统接入到OB集群，计划将ERP系统以及其他管理业务系统引入OB并优化集群建立方式加强闪存集群的建设以及加强OOS二次备份的规则利用多一次的机会保障系统稳定安全。