OceanBase 4.2 查看变量修改

[Livedba]

【 使用环境 】生产环境
【 OB or 其他组件 】OB4.2
【 使用版本 】社区版
【问题描述】OB租户的一些连接参数(ob_query_time max_user_connections)被人误修改了 导致业务连接断开，OCP上没有查看到修改记录，应该是在终端用命令行方式修改的，从oceanbase.CDB_OB_SYS_VARIABLES 视图中只能看到修改时间，有没有方法可以看到是哪个用户进行修改的
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

[论坛小助手]

日志采集场景: SQL执行出错
日志采集命令: obdiag gather scene run --scene=observer.sql_err --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

为了更好地帮助您确定是哪个用户修改了OB租户的连接参数，建议使用obdiag工具进行日志采集。上述命令将收集与SQL执行错误相关的日志信息，这有助于我们了解具体的修改操作及其执行者。

另外，为了更准确地定位问题，请您提供以下信息：

1. 修改发生的具体时间或大致时间段。
2. 是否有其他管理员或用户在同一时间段内进行了操作？
3. 业务连接断开时是否有特定的错误码或报错信息？
4. 您提到从oceanbase.CDB_OB_SYS_VARIABLES视图中只能看到修改时间，请问具体能看到哪些信息？例如：变量名称、修改前后的值等。
5. 除了ob_query_time和max_user_connections这两个参数外，是否还有其他系统变量也被修改？

同时，您可以尝试查询gv$sys_variable_history视图，该视图记录了一定时间内系统变量的历史变更记录，包括修改人信息。查询语句如下：

SELECT * FROM gv$sys_variable_history WHERE name IN ('ob_query_time', 'max_user_connections') ORDER BY modify_time DESC;

请根据以上建议进行操作，并将收集到的日志压缩包以及相关信息提供给我们，以便进一步分析问题原因。

附上敏捷诊断工具 obdiag 使用帮助链接

[Livedba]

@论坛小助手

gv$sys_variable_history

没有找到gv$sys_variable_history这个视图

[论坛小助手]

抱歉，无法从检索到的文档中找到解决此问题的信息。请联系OceanBase的人工答疑以获取更多帮助。

基于我的内在知识，可能的解答是：在 OceanBase 社区版中，并不存在 gv$sys_variable_history 这个视图来记录系统变量的历史变更信息。因此，如果需要追踪是谁修改了某些系统参数，建议采取以下措施：

1. 启用 SQL 审计日志：

   • 如果尚未开启 SQL 审计功能，可以考虑开启它。SQL 审计能够记录所有对数据库的操作，包括但不限于 DDL、DML 和设置全局/会话级别的参数等。
   • 开启命令如下（需具备相应权限）：

     ALTER SYSTEM SET enable_sql_audit = true;
     

2. 检查现有审计日志：

   • 如果之前已经启用了 SQL 审计，则可以通过查询 __all_virtual_sql_audit 视图来查找相关的修改记录。例如，要查找特定时间段内关于 ob_query_time 和 max_user_connections 参数的修改操作，可以使用类似下面的查询语句：

     SELECT * FROM __all_virtual_sql_audit WHERE sql_text LIKE '%SET GLOBAL ob_query_time%' OR sql_text LIKE '%SET GLOBAL max_user_connections%' AND gmt_create BETWEEN 'start_time' AND 'end_time';
     

   • 请注意替换 'start_time' 和 'end_time' 为实际的时间范围。

3. 加强权限管理：

   • 确保只有授权人员才能执行敏感操作，比如更改关键配置项。可以通过限制用户权限或者创建专门的角色来进行更细粒度的控制。

4. 定期备份配置文件：

   • 对于重要的配置文件和参数设置，建议定期进行备份，以便在出现问题时能够快速恢复到正常状态。

5. 监控与告警：

   • 利用 OCP 或其他监控工具设置针对重要参数变化的实时告警机制，一旦检测到异常变动立即通知相关人员处理。

希望以上建议能帮助您更好地管理和保护您的 OceanBase 实例。如果有任何疑问或需要进一步的帮助，请随时联系官方技术支持团队。

具体信息可参考以下文档:

1. GV$SYSSTAT
2. GV$ACTIVE_SESSION_HISTORY
3. GV$OB_ACTIVE_SESSION_HISTORY
4. GV$OB_SS_LOCAL_CACHE
5. V$OB_QUERY_RESPONSE_TIME_HISTOGRAM
6. GV$OB_SYS_TIME_MODEL
7. ASH_REPORT
8. GV$OB_QUERY_RESPONSE_TIME_HISTOGRAM
9. GV$OB_TABLET_COMPACTION_HISTORY

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

[独善其身]

应该可以考虑看看sys_variable_history这个试图吧

[ljware]

论坛小助手需要持续进化

[Livedba]

没有这个视图

[Livedba]

MySQL租户可以进行用户审计不

[辞霜]

select * from dba_ob_rootservice_event_history where event=‘admin_set_config’ and value2 like ‘%stack_size%’;
value2 是参数关键字’

[Livedba]

找不到过滤条件值

[try_again]

select MODIFY_TIME,TENANT_ID,NAME,VALUE,ISDEFAULT,DEFAULT_VALUE from DBA_OB_SYS_VARIABLES where tenant_id=’’ and modify_time = ‘’ ;
这样查查看

[Livedba]

这个是租户本身的视图也只能查到修改时间

[Livedba]

辞霜老师 ，社区版OB还有没有别的方法，除了审计视图外

[辞霜]

如果是修改这两个变量导致业务连接断开OCP无修改记录，可以推理出肯定是黑屏登录的当前业务用户修改了全局变量。
通过dba_ob_rootservice_event_history也是只能查询到黑屏登录的业务用户和修改时间没什么效果。

[辞霜]

这种应该就属于DBA人员的误操作了