ORA-00060是Oracle数据库中常见的死锁错误，当多个会话互相等待对方持有的锁资源时就会触发该错误，同时数据库会自动生成对应的trace文件记录死锁详情。通过分析trace文件的内容，我们可以精准判断死锁类型，找到问题根源。
获取ORA-00060对应的trace文件
首先需要在数据库告警日志中找到ORA-00060错误对应的记录，告警日志中会明确标注trace文件的存储路径和文件名，通常路径为$ORACLE_BASE/diag/rdbms/实例名/实例名/trace目录，文件名格式一般为实例名_ora_进程号.trc。
如果是测试环境，也可以手动触发死锁后直接到上述目录查找最新生成的trace文件，以下是模拟行级死锁的测试代码：
-- 会话1执行 UPDATE test_table SET col1 = 1 WHERE id = 1; -- 会话2执行 UPDATE test_table SET col1 = 2 WHERE id = 2; -- 会话1再执行 UPDATE test_table SET col1 = 3 WHERE id = 2; -- 会话2再执行 UPDATE test_table SET col1 = 4 WHERE id = 1; -- 此时会触发ORA-00060错误，生成对应trace文件
trace文件核心结构解析
打开trace文件后，重点关注以下几个核心部分：
- Deadlock Type字段：直接标注死锁的类型，这是判断死锁类型最直接的依据
- Session Information：记录参与死锁的会话ID、用户、客户端信息等
- Wait State：记录每个会话等待的锁类型、锁模式、等待的资源对象
- Current SQL Statement：记录死锁发生时每个会话正在执行的SQL语句
常见死锁类型判断方法
行级死锁（Row-Level Deadlock）
如果trace文件中Deadlock Type字段显示为ROW，或者Wait State中的锁类型为TX（事务锁），等待资源为具体的数据行，同时SQL语句是UPDATE、DELETE这类行操作语句，就可以判定为行级死锁。这是最常见的死锁类型，通常是业务中对多行数据的更新顺序不一致导致的。
表级死锁（Table-Level Deadlock）
如果Deadlock Type为TABLE，或者Wait State中的锁类型为TM（表级锁），通常是因为执行DDL语句（如ALTER TABLE）时和其他会话的DML操作互相阻塞导致。比如一个会话正在对表做ALTER操作，另一个会话同时对该表执行INSERT，就可能触发这类死锁。
其他类型死锁
还有少见的死锁类型比如ITL Deadlock（事务槽死锁），这类死锁会在trace文件中标注ITL相关字样，通常是因为表的INITRANS参数设置过小，事务槽不足导致，需要调整表的存储参数解决。
实际分析示例
以下是一个真实trace文件中截取的核心片段：
Deadlock Type: ROW Session 1: sid=123 serial=456 Wait State: type=TX mode=6 request=6 Wait Resource: object=TEST_TABLE rowid=AAASeFAAEAAAAIjAAA Current SQL: UPDATE test_table SET col1 = 3 WHERE id = 2 Session 2: sid=789 serial=012 Wait State: type=TX mode=6 request=6 Wait Resource: object=TEST_TABLE rowid=AAASeFAAEAAAAIiAAA Current SQL: UPDATE test_table SET col1 = 4 WHERE id = 1
从这段内容可以明确看到Deadlock Type为ROW，锁类型是TX，两个会话互相等待对方更新的行，属于典型的行级死锁，解决方法是统一业务中多行数据的更新顺序，避免交叉更新。
总结
通过trace文件诊断ORA-00060死锁类型的核心是先找到对应trace文件，再重点关注Deadlock Type字段和锁类型、等待资源、当前SQL这几个关键信息，结合实际业务场景就能快速定位问题。日常开发中建议对批量更新操作统一排序规则，避免行级死锁的发生，对表的DDL操作尽量避开业务高峰期，减少表级死锁的概率。