vici
#1
【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】ocp、ob
【 使用版本 】ocp4.3.0、ob3.2.3
【问题描述】清晰明确描述问题 ocp告警,查询sys租户sys数据库中不存在的视图
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!
论坛小助手
#3
根据您提供的信息和日志片段,您的问题主要集中在 OCP 查询 sys
租户时遇到了视图不存在的错误。具体表现为查询某些视图(如 GV$PLAN_CACHE_REFERENCE_INFO
, GV$OB_SQL_WORKAREA_MEMORY_INFO
等)时,提示这些视图不存在或权限不足。
分析与解决方案
1. 视图不存在的原因
在 OceanBase 中,sys
租户是系统租户,包含了系统级别的元数据和监控信息。某些视图可能在特定版本中存在差异或未被正确初始化。根据您的环境信息(OCP 4.3.0 和 OB 3.2.3),可能存在以下原因:
-
版本兼容性问题:某些视图可能在 OB 3.2.3 版本中尚未引入或存在差异。
-
初始化问题:
sys
租户中的某些视图可能未被正确初始化或创建。
2. 权限问题
从日志中可以看到,错误信息提到“definer/inwoker of view lack rights to use them”,这表明可能是权限不足导致无法访问这些视图。确保当前登录 OCP 的用户具有足够的权限来访问 sys
租户中的视图。
3. 检查 OCP 和 OB 的连接状态
根据文档片段 2,OCP 与 OceanBase 集群之间的连接问题也可能导致类似的错误。请检查:
- OCP 与 OBServer 之间的网络连接是否正常。
- OCP 是否能够成功连接到
sys
租户。
-
sys
租户的账号和密码是否正确。
4. 检查 OCP 版本兼容性
根据文档片段 6,OCP 在不同版本的 OceanBase 上可能存在功能适配问题。建议确认 OCP 4.3.0 是否完全兼容 OB 3.2.3,并查看是否有已知的兼容性问题或修复方案。
解决步骤
-
确认视图是否存在
-
检查权限
- 确保当前登录 OCP 的用户具有访问
sys
租户的权限。可以尝试使用具有更高权限的管理员账号进行查询。
-
检查连接状态
- 使用 OCP 的监控功能或命令行工具(如
obd
)检查 OCP 与 OBServer 之间的连接状态。
- 确认
sys
租户的账号和密码是否正确。
-
升级或更新 OCP
- 如果发现 OCP 4.3.0 存在兼容性问题,考虑升级 OCP 或应用最新的补丁。
-
联系支持
- 如果以上步骤无法解决问题,建议联系 OceanBase 的官方技术支持团队,提供详细的日志和环境信息,以便进一步诊断。
参考文档
希望以上信息能帮助您解决 OCP 查询 sys
租户视图不存在的问题。如果还有其他疑问,请随时联系 OceanBase 的官方支持团队。
详情请参考:
- 查看 SQL 详情
- ob_cluster_status_check_failed OB 集群状态检测失败
- OCP V3.3.0
- 查看租户总览
- OCP V4.0.0
- ob_host_connection_percent_over_threshold OB 服务器连接数百分比超限
- 新建单机集中式数据库
- OCP V4.3.0
- OCP V3.1.2
旭辉
#4
参考小助手的回复,确实是版本问题,ob3.2.3,ocp4.3.0 这个版本跨度比较大,建议升级OB到最新LTS版本
vici
#5
这个报错可以忽略的对吧。是什么任务触发的查询。看告警日志每天凌晨2点都在报错。但是我们的合并是在四点钟的
论坛小助手
#6
根据您提供的信息,告警日志显示每天凌晨2点触发的查询导致了视图不存在或权限不足的错误。而您的合并任务是在凌晨4点进行的。为了更准确地判断这个报错是否可以忽略以及是什么任务触发了这些查询,我们可以从以下几个方面进行分析和处理。
1. 确认告警来源
检查 OCP 定时任务
OCP 中可能存在定时任务在特定时间点执行某些操作,例如监控、备份、性能诊断等。您可以检查 OCP 的定时任务配置,确认是否有任务在凌晨2点触发查询。
-
查看 OCP 定时任务:
- 登录 OCP 控制台。
- 导航到“任务管理”或“定时任务”页面。
- 查看是否存在定时任务在凌晨2点执行,并确认这些任务的具体内容。
检查系统默认配置
根据文档片段 2,OceanBase 默认会在每天凌晨2点进行全量合并(major_freeze_duty_time
)。虽然您提到合并任务是在凌晨4点,但系统默认配置可能会触发其他类型的查询或任务。
-
检查
major_freeze_duty_time
配置:
2. 分析告警日志
日志中的具体任务
从日志中可以看到多个视图查询失败的信息,这些查询可能来自不同的监控或诊断任务。建议详细分析日志中的 trace_id
和 task_id
,以确定具体的任务类型。
-
查找具体的任务 ID:
- 使用日志中的
trace_id
登录到对应的 OBServer 节点上搜索日志。
- 确认这些任务的具体来源和目的。
日志中的错误类型
日志中提到的错误主要是视图不存在或权限不足。如果这些视图是系统内部使用的监控视图,且不影响业务逻辑,理论上可以忽略这些告警。但为了确保系统的稳定性和完整性,建议进一步确认这些视图的作用。
3. 判断告警的影响
是否影响业务
如果这些查询仅用于监控或诊断,且不会影响业务数据的一致性和完整性,那么这些告警可以暂时忽略。但建议定期检查并修复这些问题,以避免潜在的风险。
是否需要修复
即使这些告警不影响业务,也建议修复这些问题,以减少不必要的日志噪音和提高系统的可维护性。
4. 解决方案
调整定时任务
如果确认是某个定时任务在凌晨2点触发了这些查询,可以考虑调整该任务的执行时间,避免与合并任务冲突。
-
调整 OCP 定时任务:
- 在 OCP 控制台中修改相关定时任务的执行时间。
- 确保新的执行时间不会与其他关键任务冲突。
修改合并时间
如果您希望保留现有的合并时间(凌晨4点),可以考虑将其他定时任务调整到非高峰时段。
-
修改
major_freeze_duty_time
:
检查视图权限
如果问题确实是由于权限不足引起的,确保相关用户具有足够的权限访问这些视图。
-
授予必要权限:
- 确认 OCP 使用的账号是否具有访问
sys
租户中所有必要视图的权限。
- 必要时,授予相应的权限。
总结
根据以上分析,建议您首先确认告警的具体来源,特别是哪些任务在凌晨2点触发了这些查询。如果这些查询仅用于监控或诊断且不影响业务逻辑,理论上可以忽略这些告警。但为了确保系统的稳定性和完整性,建议进一步调查并修复这些问题。同时,考虑调整定时任务的执行时间以避免冲突。
如果您需要进一步的帮助或有更多疑问,请随时联系 OceanBase 的官方技术支持团队。
具体信息可参考以下文档:
- 数据导入策略与最佳实践
- 定时触发合并
- 更新数据
- 诊断实践:使用 SQL_PLAN_MONITOR 分析性能问题
- 数据备份失败
- UPDATE
- Switchover 或 Failover 相关问题
- 分页查询
- 自动触发合并
(小助手的答复已结束,如未能解决您的问题,请继续提问并等待其他同学的回复,谢谢!)
旭辉
#7
应该是可以忽略掉的,可以看下observer.log有没有比较严重的报错,另外3.2.3是企业版,
可以通过以下方式寻求帮助:
1.如你所在的企业客户已签署OceanBase企业版销售合同,请你联系客户经理;
2.如你所在的企业客户尚未签署OceanBase企业版销售合同,你可通过OceanBase官网商务咨询页面留下你的联系方式,OceanBase企业版的业务顾问会在一个工作日内与你联系。
OceanBase官网商务咨询
https://www.oceanbase.com/contactus?fromPage=https%3A%2F%2Fwww.oceanbase.com%2Fsoftwarecenter-enterprise&dataSources=softwarecenter-enterprise_footercontact_d2022