最近总是碰到锁问题，

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境 生产环境
【 OB or 其他组件 】 4.2
【 使用版本 】 4.2
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

问题1：
前一天晚上，一个应用下反馈某笔业务失败，想知道当时是否成功获取到锁了，或者有锁冲突？

请问如何检查这种一天前的问题？是否这能用sqlaudit？

#3

根据文档库中的信息，您可以使用以下 SQL 查询来检查某个日志流的迁移/复制/Rebuild 任务执行历史，这可能有助于您了解当天是否存在锁冲突或锁获取失败的情况：

select * from DBA_OB_ROOTSERVICE_EVENT_HISTORY
where module like "%disaster%" and value1 = $TENANT_ID and value2 = $LS_ID;

其中 finish 事件中的 name6 和 value6 记录了任务的执行结果：ret 字段为 0 说明该次任务执行成功，非 0 说明该次任务执行的报错结果；elapsed 字段记录该次任务的执行时长；ret_comment 描述了失败的原因，如果没有失败的报错信息，可以拿对应 task_id 去当时的 Root Service 上搜索相关的日志。

grep "$TASK_ID" rootservice.log*

此外，对于锁问题，您还可以通过查询 gv$transaction 视图来查看当前的事务状态，以及 gv$lock 视图来查看当前的锁持有情况。这些视图可以帮助您了解当前是否有事务持有锁，以及锁的类型和持有时间等信息。但是，这些视图只能提供当前的状态信息，对于过去一天的问题，您可能需要结合日志文件进行分析。

至于 sqlaudit，它主要用于审计 SQL 执行的历史记录，包括执行时间、执行用户、执行的 SQL 语句等信息，但不直接显示锁的获取情况。因此，对于锁问题的排查，建议还是先从日志和上述视图入手。

希望以上信息对您有所帮助！如果还有其他疑问，欢迎继续提问。

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

  1. 6000 ~ 6999
  2. 节点日志盘（Clog）空间满
  3. 迁移/复制/Rebuild
  4. SQL 调优典型场景和案例
  5. MySQL 兼容应用错误处理规范
  6. case 编写常用命令
  7. 数据备份失败
#4

可以搜下日志是否有rollback字样，然后可以提取相关日志获取traceid进而获取表及sql

另外锁相关的问题可以参考下

事务超时，错误代码 ERROR 4012

https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000217854?back=kb

行锁问题排查介绍

https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001012955?back=kb

OceanBase 数据库 V4.2 版本，关于锁冲突问题的排查手册

https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000664387?back=kb&_gl=11a9lg8f_gaMTIwMjU5NTAzNC4xNzE0OTc1MTY1_ga_T35KTM57DZ*MTczMjg1ODM2MS4zNTMuMS4xNzMyODY2ODM2LjYwLjAuMA…

#5

可以搜下日志是否有rollback字样，然后可以提取相关日志获取traceid进而获取表及sql

→ 我们同事是通过查询 where 条件的参数 "CNYN00000000007703809 进行检查。

查看此ocp时间范围内执行SQL，存在update 更新表操作，与for update冲突导致
grep “CNYN00000000007703809” |observer.log

#6

根据您提供的信息，您的同事已经通过查询 where 条件的参数 "CNYN00000000007703809" 进行了检查，并且发现了在 OCP 时间范围内执行的 SQL 存在 UPDATE 操作，这可能是导致锁冲突的原因之一。为了进一步确认这个问题，您可以按照以下步骤进行详细的日志分析和 SQL 审计：

1. 搜索日志中的 rollback 字样

首先，您可以在 observer.log 中搜索 rollback 字样，以确定是否有事务回滚的情况发生。这可以帮助您确认是否存在锁冲突导致的事务回滚。

grep "rollback" /path/to/observer.log

2. 提取相关日志获取 trace_id

如果找到了包含 rollback 的日志条目，您可以进一步提取这些日志条目中的 trace_id。trace_id 是 OceanBase 中用于跟踪事务和 SQL 执行的重要标识符。

grep "CNYN00000000007703809" /path/to/observer.log

假设您找到了以下日志条目：

[2023-03-22 14:30:33.124342] [38419][T1_L0_G0][T1][YB42AC1E87CC-0005F6BFDB3E2199-0-0] {"trace_id":"0005f777-4c14-595f-508c-6681b3dac7c9","name":"pc_get_plan","id":"0005f777-4c14-59f1-5c54-a90e3ff82e85","start_ts":1679466633124337,"end_ts":1679466633124340,"parent_id":"0005f777-4c14-59ef-de27-961b48ecfdfd","is_follow":false}

从这条日志中，您可以提取出 trace_id 为 YB42AC1E87CC-0005F6BFDB3E2199-0-0。

3. 使用 trace_id 查询 SQL 审计日志

接下来，您可以使用提取到的 trace_id 查询 SQL 审计日志，以获取具体的 SQL 语句和执行情况。

-- MySQL 模式
SELECT * FROM oceanbase.__all_virtual_sql_audit WHERE trace_id = 'YB42AC1E87CC-0005F6BFDB3E2199-0-0';

-- Oracle 模式
SELECT * FROM sys.__all_virtual_sql_audit WHERE trace_id = 'YB42AC1E87CC-0005F6BFDB3E2199-0-0';

4. 分析 SQL 审计日志

在 SQL 审计日志中，您可以查看具体的 SQL 语句、执行时间、执行用户等信息。特别关注 sql_text 和 plan_id 字段，以确定是否有 UPDATE 操作与其他事务的 FOR UPDATE 操作冲突。

5. 使用 OCP 查询链路信息

如果您使用 OCP，还可以通过 OCP 查询链路信息来进一步分析问题。

  1. 登录 OCP。
  2. 在左侧导航栏中选择 系统管理 > 日志服务。
  3. 单击 链路查询 页签，进入 链路查询 界面。
  4. 通过在 链路查询 界面中设置查询条件，辅助定位目标 Trace。
  5. 单击 查询 按钮。将光标悬停至 span 节点的时间轴上，在弹窗中将展示 span 的详细信息。

6. 检查 gv$transaction 和 gv$lock 视图

最后，您可以检查 gv$transaction 和 gv$lock 视图，以了解当前的事务状态和锁持有情况。

-- 查看当前事务状态
SELECT * FROM oceanbase.gv$transaction;

-- 查看当前锁持有情况
SELECT * FROM oceanbase.gv$lock;

通过以上步骤，您应该能够更详细地了解锁冲突的具体情况，并找到导致问题的根本原因。希望这些信息对您有所帮助！如果还有其他疑问，欢迎继续提问。

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

  1. base_secondary_backup_fail 数据二次备份任务失败
  2. inc_backup_delay 日志备份延迟
  3. odp_sql_execute_failed SQL 执行失败次数超限
  4. 查询链路
  5. 执行计划变动导致性能变差
  6. 查看信息采集详情
  7. 基于 Trace 功能查找上一次 SQL 请求日志
  8. ENABLE_OPT_TRACE
  9. 分析响应时间突然抖动的 SQL
  10. 并行执行问题诊断
  11. 日志服务
  12. 查看日志流升降级相关信息
  13. 全链路追踪展示

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

#7

可以的，这个锁冲突大概率是业务逻辑设计方面不够优